前言：從首頁到詳細頁，整條使用者流程怎麼串起來？

前幾天我們已經分別看過首頁、查詢結果和詳細頁，也知道各個 ViewModel 大概在做什麼。

但如果現在問我：「使用者從首頁開始查一間空教室，到最後看到這間教室的詳細資料，中間到底發生了什麼？」

我以前其實沒辦法一次講完整。每個檔案我好像都看過，但它們還是分開的；所以今天，我想先不看新的功能，而是把前面讀過的程式重新串一次。

目前為止，我們討論了以下這幾個檔案：

• AndroidManifest.xml：指定 App 啟動入口。
• MainActivity.kt：首頁，讓使用者選大樓。
• QueryResultActivity.kt：查詢頁 UI 控制器。
• QueryResultViewModel.kt：查詢條件與空教室篩選核心。
• EmptyRoomAdapter.kt：把 emptyRooms 顯示成 RecyclerView 列表。
• RoomDetailActivity.kt：教室詳細頁 UI 控制器。
• RoomDetailViewModel.kt：根據教室名稱取得詳細資料。

Day 10 的目標是從「分開看懂每個檔案」進一步變成「能說出它們如何合作」，這也是為什麼我會特別拉出一個主題來說明。

使用者查詢流程總結

1. App 啟動：使用者怎麼進入首頁？

App 的開啟入口是 AndroidManifest.xml 這個設定檔，但進入的第一個畫面是 MainActivity。

流程是：使用者點 App 圖示 → Android 讀 Manifest → 找到 MAIN + LAUNCHER → 啟動 MainActivity。

2. 選擇大樓：查詢條件怎麼傳出去？

MainActivity.kt 處理首頁 UI 互動邏輯，讓使用者選擇大樓，並透過 Intent 把大樓名稱傳給 QueryResultActivity。

流程是：首頁選大樓 → 按查詢 → Intent 帶著 building → 前往 QueryResultActivity。

3. 設定查詢條件：查詢頁怎麼接住使用者的選擇？

QueryResultActivity.kt 是查詢頁 UI 控制器。
接收首頁傳來的大樓條件，設定星期、時段、樓層三個 Spinner，並在使用者改變選項時，把目前選到的值寫進 QueryResultViewModel。同時觀察 emptyRooms，讓 Adapter 更新 RecyclerView。

4. 執行查詢：空教室是怎麼被篩選出來的？

QueryResultViewModel .kt 是從 SavedStateHandle 取得 building，接收 QueryResultActivity 選的日期、時段、樓層。
當條件都準備好後，update() 會把中文大樓轉成 SF/ES，把星期與節次轉成 mon1 等欄位代碼，然後篩選所有教室。只有大樓符合、樓層符合，而且該時段欄位不是 X 的教室，才放進 emptyRooms。

5. 顯示結果：emptyRooms 怎麼變成畫面上的列表？

EmptyRoomAdapter.kt 接收 QueryResultViewModel 已經篩選好的 emptyRooms，依教室名稱提取樓層、分組、排序，整理成包含樓層標題與教室項目的 items。
RecyclerView 根據每一列型別建立對應 ViewHolder。點擊教室項目時，Adapter 透過 callback 把該教室資料傳回 QueryResultActivity。

6. 點進教室：使用者選到的教室怎麼傳到詳細頁？

RoomDetailActivity.kt 是詳細頁 UI 控制器。
如果沒有取得教室名稱，就關閉頁面。取得教室名稱後，呼叫 viewModel.getDetails(name) 並觀察回傳資料。
查到 ClassroomSchedule 後，updateUi() 顯示教室名稱，將 classroomType（教室類型）轉成中文，並依是否為 Normal（一般教室） 判斷能否飲食。

7. 取得詳細資料：詳細頁怎麼找到這間教室？

RoomDetailViewModel.kt 是教室詳細頁的邏輯中心。
根據 classroomName 透過 Repository 取得該教室的 ClassroomSchedule，用 asLiveData() 將 Repository 回傳的資料流轉成 LiveData<ClassroomSchedule?>，讓 RoomDetailActivity 可以 observe。

完整流程圖

AndroidManifest.xml
        ↓
設定 App 入口
        ↓
MainActivity
        ↓
傳遞選擇的大樓 building
        ↓
QueryResultActivity
        ↓
取得／記錄查詢條件
星期／時段／樓層
        ↓
QueryResultViewModel
        ↓
依大樓、樓層、時段篩選 ClassroomSchedule
        ↓
取得空教室 emptyRooms
        ↓
Activity 觀察結果並整理列表
        ↓
EmptyRoomAdapter / RecyclerView
        ↓
使用者點選教室
        ↓
傳遞 classroomName
        ↓
RoomDetailActivity
        ↓
查詢該教室詳細資料
        ↓
RoomDetailViewModel
        ↓
Repository → LiveData
        ↓
RoomDetailActivity
        ↓
顯示教室名稱、教室類型、是否可飲食

Hermes Agent 幫我檢查出的重點

1. 使用者打開 RoomRush 時，Android 會根據 AndroidManifest.xml 中的 MAIN + LAUNCHER 啟動 MainActivity。
2. 首頁讓使用者選擇大樓，並用 Intent 把 building 傳到 QueryResultActivity。
3. 查詢頁顯示星期、時段、樓層三個 Spinner，並把使用者選到的條件寫進 QueryResultViewModel。
4. ViewModel 取得所有教室課表後，依照大樓、樓層、時段是否可用篩出 emptyRooms。
5. Activity 觀察到結果後交給 EmptyRoomAdapter，Adapter 依樓層整理列表並顯示到 RecyclerView。
6. 當使用者點擊某間教室時，QueryResultActivity 再用 Intent 把教室名稱傳給 RoomDetailActivity。
7. 詳細頁透過 RoomDetailViewModel 查到該教室資料，最後顯示教室名稱、教室類型與是否可飲食。

流程分工表

小結

整理完整使用者查詢流程後，我發現 RoomRush 的功能不是由單一檔案完成，而是由多個檔案各自負責一段

• MainActivity 負責收集第一個條件：大樓。
• QueryResultActivity 負責查詢頁互動。
• QueryResultViewModel 才是真正把條件轉成空教室列表的地方。
• EmptyRoomAdapter 則把結果整理成有樓層標題的列表。

這次總結讓我更理解 Android 專案的分工：Activity 不應該包辦所有事情，ViewModel 也不負責顯示畫面。每個檔案看起來分散，但如果沿著資料流追，就能看到它們如何一起完成「查詢空教室」這個功能。

下一篇預告：一間教室的一週課表，在資料庫裡長什麼樣子？

使用者查詢流程的第一階段在此圓滿告一段落。下一階段，我們要正式進入到「資料來源主線」。

要計算空教室，我們首先就是要搞懂資料的源頭：**「一間教室的一週課表，在 RoomRush 裡是如何被表示成 Room Entity 與資料表欄位的？」，**這部分是了解資料庫在空教室查詢系統中，很重要的一個環節。